fix(compile): pin TMP/TEMP for compiler subprocess on Windows (#875) - #885

Rolls up the fixes shipped since 2.3.14:

- #855 (#883) — drop stale standalone-zccache CI/Docker/docs references
  after the soldr embedded-zccache transition (soldr#977/#980/#1081)
- #865 (#884) — write daemon status via sync write_atomic; unblocks
  fbuild-daemon unit tests on macOS/Windows by eliminating the
  block_in_place panic in current-thread tokio runtimes
- #875 (#885) — pin TMP/TEMP for compiler subprocess on Windows; ESP32
  compile no longer fails with 'Cannot create temporary file in
  C:\Windows\' on the very first TU
- #720 (#886) — record anti-removal policy for dump_usb_ids example
- #829 (#887) — stage fbuild._native cdylib during source/editable
  install so 'from fbuild import ...' works after 'uv pip install -e .'

Plus all prior #664 platform_packages audit work, the #826 testing
followups, and the build cancellation fix from earlier in the cycle.

…indows (#890)

Follow-up to #885 (`fix(compile): pin TMP/TEMP for compiler subprocess on
Windows`). With TMP/TEMP env now propagated correctly, gcc's driver
finally manages to create its internal spec file — and as soon as it
does, the next failure mode surfaces:

  cc1plus.exe: fatal error: srcmain.cpp: No such file or directory

The driver writes args into the spec file using GCC's quoting rules,
where `\` is an escape character. So `src\main.cpp` (which
`path_arg_for_compile_cwd` returns on Windows because that's how the
host OS spells it) is parsed by cc1 as `srcmain.cpp` and fails to open.

Fix: convert backslashes to forward slashes for every path arg on
Windows. Windows GCC has always accepted both separators for filesystem
lookups; forward slashes additionally survive every spec-file /
response-file pass unchanged. POSIX hosts pass through unmodified.

Repro pre-fix (after #885):
  bash compile esp32dev --examples Blink
  → cc1plus.exe: fatal error: srcmain.cpp: No such file or directory

Post-fix: clean Blink build in 117 s on Windows.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ESP32 (#3446) (#3447)

## chip-id detection — three-strategy fallback chain (#3446)

Previously the autoresearch port detection probed each port with a
single 3.0 s esptool `chip-id` attempt using the default DTR/RTS auto-
reset. On a CP210x ESP32-WROOM devkit that budget consistently
undershoots — the realistic worst case is ~7 s (slow CP210x driver
init + ~4 s of esptool SYNC retries + bootloader handshake), so
healthy boards were misclassified as "device may not be in
bootloader mode" and the entire bring-up gave up before any test
could start.

New behaviour:

- Per-strategy timeout default is 7 s (covers the worst case while
  keeping a 5-port-all-empty sweep under ~10 s total).
- Primary strategy is still `--before default-reset`.
- ONLY when the primary attempt actually times out do we escalate to
  the fallback chain (`--before usb-reset` then `--before no-reset`).
  "Port open OK but no chip-id produced" stays a fast-path failure —
  empty ports don't drag the total budget out.
- The caller in `_resolve_port` drops its explicit `timeout=3.0`
  override so it picks up the new default and the fallback chain.

Local repro: `bash autoresearch esp32dev` with a CP210x ESP32-wroom
on COM11 now resolves to `(esp32) ESP32` on the first attempt
instead of `detection failed (esptool timed out after 3.0s)`.

## LegacyClocklessProxy — gate pin 8 on classic ESP32

`SK6812<8, RGB>` instantiation fires FastLED's
`_ESPPIN<8, 256, false>::validpin() == false` static_assert because
GPIO8 on the classic ESP32 (esp32dev / WROOM) is reserved for SPI
flash (D2/HD). Newer ESP32 variants (S2/S3/C2/C3/C5/C6/H2/P4)
repurpose GPIO8 and accept it as a valid output pin, and every non-
ESP family treats pin 8 as a normal digital — so the gate is the
narrow classic-ESP32 exclusion, not a broad change.

Mirrors the existing `AUTORESEARCH_LEGACY_SUPPORTS_PIN_22` Teensy
gate. Without this the sketch failed at compile time for esp32dev
and autoresearch never got past the build phase.

## pyproject.toml — fbuild 2.3.15 pin note + version chase

The pin stays at `fbuild==2.3.14` for now (2.3.15 isn't on PyPI yet
as of this commit) but the comment history is updated to reflect the
Windows compile env + path-separator fixes that landed in
FastLED/fbuild#885 and FastLED/fbuild#890. Bump the pin to 2.3.15 in
a follow-up once the release workflow publishes.

Closes (pending CI): #3446

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…path (#912)

* feat(cli): fbuild sync + platformio.lock (#618 Phase 1)

Implements Phase 1 of the roadmap in #618: fbuild sync
reads platformio.ini, classifies every lib_deps entry per env, and
writes a deterministic JSON platformio.lock next to the ini. All
flags in the issue proposal land: -e <env>, --yes, --locked, --check,
--dry-run, --upgrade, --upgrade-package. Multi-env prompt gates
whole-project sync; --yes / -e / --check bypass it.

# Scope

Phase 1 is a full CLI + classification + lockfile-shape ship. Network
resolution (GitHub ref -> SHA, PIO registry version -> archive URL,
archive sha256) is deferred to Phase 2 per the issue's staged rollout.
Every remote entry gets status: "unresolved" with the raw spec +
extracted owner/name/ref captured, so Phase 2 will only add fields,
never renegotiate the schema.

Local sources (symlink://, file://, filesystem paths — absolute POSIX,
relative ./ / ../, Windows drive letters) get status: "unlocked"
and are recorded verbatim for auditability.

# Files

Module layout (kept as one focused directory tree, three files, no
new crate — respects the monocrate rule):

- crates/fbuild-cli/src/sync/mod.rs        — orchestrator + SyncArgs
                                              + run_sync + prompt logic
- crates/fbuild-cli/src/sync/source.rs     — SourceType + LockStatus
                                              + ClassifiedDep + classify()
- crates/fbuild-cli/src/sync/lockfile.rs   — Lockfile struct + JSON I/O
                                              + LockDiff comparison
                                              + atomic write via
                                                fbuild_core::fs::write_atomic_sync
                                                (from #865)
- crates/fbuild-cli/src/cli/sync_cmd.rs    — thin CLI adapter
- crates/fbuild-cli/src/cli/args.rs        — new Commands::Sync variant +
                                              KNOWN_SUBCOMMANDS entry
- crates/fbuild-cli/src/cli/dispatch.rs    — wire the new command
- crates/fbuild-cli/src/cli/mod.rs         — register sync_cmd
- crates/fbuild-cli/src/main.rs            — register sync module
- docs/sync.md                             — user-facing docs
- docs/CLAUDE.md                           — index entry

# Lockfile schema (v1)

- envs sorted alphabetically (BTreeMap)
- packages per env sorted by (name, source_type, raw)
- generated_at trimmed to seconds (ISO-8601 UTC)
- fields with a documented consumer only (no decorative registry
  metadata — per issue decision)
- package records DUPLICATED under each env (per issue decision:
  auditability > disk size)
- read() refuses to load an unrecognized version — schema evolution
  is versioned

# TDD-first — 30+ unit tests written before implementation

Written first, then wired up:

- crates/fbuild-cli/src/sync/source.rs::tests — 18 tests covering
  every documented lib_deps shape:
    - Registry: bare name, name@ver, owner/name@ver, whitespace,
      raw preservation
    - GitHub: bare URL, .git suffix, #ref, case-insensitive host
    - Git+: URL, ref
    - HTTP archive: .zip, .tar.gz
    - Local: symlink://, file://, ./relative, ../relative,
      /posix-abs, C:\ backslash, D:/ forward-slash
    - phase1_lock_status returns Unlocked for locals, Unresolved
      for remotes

- crates/fbuild-cli/src/sync/lockfile.rs::tests — 10 tests:
    - Shape smoke
    - Packages sorted by name
    - Envs sorted
    - Local dep -> Unlocked
    - Registry dep -> Unresolved in Phase 1
    - JSON deterministic for same input (regardless of insertion
      order)
    - Read/write roundtrip
    - Version mismatch rejected
    - compare fresh/stale detection (new dep added, env added,
      version changed)
    - JSON ends with newline

- crates/fbuild-cli/src/sync/mod.rs::tests — 11 tests:
    - Missing platformio.ini is error
    - Single env writes lockfile
    - --check on missing lock is failed
    - --check on fresh lock passes
    - --locked on stale lock returns LockedFailed
    - --dry-run writes nothing
    - -e <env> skips multi-env prompt
    - -e <bad-env> is error
    - Second run without changes is NoOp
    - exit_code matrix (Wrote/NoOp/CheckPassed/DryRun=0,
      CheckFailed=1, LockedFailed=2, UserCancelled=3, Error=4)
    - skip_multi_env_prompt matrix
    - ISO date formatter basic + time-of-day

# Local verification

- `soldr cargo check -p fbuild-cli --all-targets` — clean
- `soldr cargo clippy -p fbuild-cli --all-targets -- -D warnings` — clean
- `soldr cargo test -p fbuild-cli --no-run` — clean (test binaries build)
- `soldr cargo fmt -p fbuild-cli` — no-op

Note on test execution: my local environment (soldr silently swallows
all stdout/stderr; direct-cargo hits Windows SDK linker env issues
that this session has documented at length in #899) prevents me from
running the test binary end-to-end today. Every test is pure enough
that the compile-clean under -D warnings + the TDD-first authoring
order gives strong confidence, and CI will exercise them on Linux.

Closes #618

* fix(sync): allow dead_code on Phase 2 hook fields (#618 CI fix)

CI on macos/windows failed with clippy `-D dead-code`:
- SyncArgs.upgrade + upgrade_package — Phase 2 fields, captured from
  the CLI now so the argv surface is stable but not yet consumed.
- SyncOutcome::Wrote(PathBuf) — payload used by structured callers
  (tests + future --json subcommand). Clippy doesn't see the tests
  as consumers.

Annotate with #[allow(dead_code)] at the field / enum level with a
comment pointing at #618's Phase 2.

* fix(compile): rewrite backslashes in source/output args on the no-compile-CWD fallback path

Windows PIO builds under `.build/pio/<board>/` don't have a `.fbuild`
component upstream of the output path, so `compile_cwd_from_output()`
returns None and `compile_source()` fell through to the raw
`to_string_lossy()` on the source/output paths. That leaves
backslashes intact in argv, which GCC's internal spec-file pass
interprets as escape characters:

  `-c src\sketch\AutoResearchNet.cpp` → cc1plus.exe receives
  `srcsketchAutoResearchNet.cpp` → "fatal error: srcsketchAutoResearchNet.cpp: No such file or directory".

Symptomatically identical to the fix that landed in #875 / #885 for
the compile-CWD arm; the fallback arm was missed. Mirror the same
`replace('\', "/")` guard so both paths agree on Windows.

Bump workspace version 2.3.15 → 2.3.16.

Repro: `bash compile esp32dev --examples AutoResearch` from a
FastLED checkout on Windows failed at the first .cpp compile with
`srcsketchAutoResearchNet.cpp` / `srcsketchAutoResearchBle.cpp`
etc. After this fix, the compile completes end-to-end.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…#1372)

* ci(dylint): add a Windows leg so Windows-only code is actually linted

Closes #1359.

`cargo check` only compiles the modules the target platform selects, so a
ubuntu-only Dylint job never sees a single `#[cfg(windows)]` or
`platform/windows/**` module. The lint suite is the enforcement arm for most
of this repo's path invariants, and Windows is where the bugs those lints
exist to prevent actually bite — #875, #885, #890 and #912 were all Windows
path handling. The gate was pointed away from the platform that needs it.

Not hypothetical. A full sweep on a Windows host against main reports:

    error: use fbuild_core::path::NormalizedPath::display_slash() instead of
           hand-rolled backslash-to-slash rewrite
      --> crates\fbuild-core\src\platform\windows\fs.rs:21:17

## Fixing the violation, not excusing it

`ban_manual_slash_normalize` allowlisted `fbuild-core/src/path.rs` as "the
primitive itself". The platform-facade migration (#1306) then moved the actual
`\` -> `/` rewrite into the per-OS `platform::fs::display_slash`, leaving
`NormalizedPath::display_slash` a one-line delegation — `path.rs` no longer
performs the transformation at all.

So the entry moves rather than being added alongside: the Windows
implementation is the definition site now, and `path.rs` is dropped from this
lint's allowlist. Keeping it "just in case" is how the list drifted out of
step with the code in the first place. `path.rs` keeps its entries on the
*other* lints, which it still earns.

Crate version bumped, per the convention in its own manifest: the allowlist is
embedded in the `.so`, and a stale cached copy on the ubuntu leg would
silently skip enforcing the removal.

## The workflow change

A matrix with per-leg pinned `name`, not a derived one. `Dylint` is a required
status check, and letting the matrix rename the ubuntu leg to
`Dylint (ubuntu-latest)` would leave that required check permanently pending
on every PR. The ubuntu leg keeps reporting as exactly `Dylint`; the Windows
leg is additive as `Dylint (windows)`. `fail-fast: false`, so a Windows
violation cannot mask a Linux one.

`defaults.run.shell: bash` for Git Bash on the Windows runner — the steps use
process substitution and POSIX `find`, which PowerShell cannot parse. And
`CARGO_HOME` is now defaulted where it was assumed: unset, `export
PATH="${CARGO_HOME}/bin:..."` would silently prepend a bare `/bin`.

## Verified on Windows, which is the new leg

Every step of the job was run locally on a Windows host:

- full `dylint --all -- --workspace --all-targets` sweep: **0 violations**
- the observed-comparison that closes the job
  (`enforce_platform_boundary.py --dylint-observed`): passes, `rows=14;
  dylint_rows=14` — a per-OS row disagreement was the likeliest way this leg
  could have failed for reasons unrelated to violations
- the fmt loop and the test loop over all **27** lint crates: clean
- `check_dylint_allowlists.py`, `render_workflows.py --check`, and
  `check_workflow_concurrency.py`: pass

## Not included: a macOS leg

Same one-line matrix addition, deliberately deferred. `platform/macos/**` has
never been linted by anyone, so its first run is pure discovery — and I have
no way to triage it, having no macOS host. Windows has a demonstrated
violation and local evidence; macOS has neither yet. Each leg also costs a
~17-30 min job on every PR push, which is worth stating rather than
discovering: if that per-PR cost is unwanted, the Windows leg is equally
useful restricted to `push: main`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* ci(dylint): scope the lint crates' own tests to the ubuntu leg

The new Windows leg went red on its first run, and the finding is worth
recording because it is not what the leg exists to catch.

The lints themselves are clean on Windows — the workspace sweep passes. What
failed is the "Test Dylint libraries" step, which runs each lint crate's own
compiletest ui fixtures:

    error: could not load library
    `.../target/dylint-tests/debug/ban_manual_slash_normalize@nightly-2026-04-16.dll`:
    LoadLibraryExW failed

Dylint 6.0.1 looks for its test library under `<target>/debug` while soldr
sets `CARGO_BUILD_TARGET`, so cargo writes to `<target>/<host>/debug`. Each
lint's `fn ui` already clears that variable — that is what the comment in
every one of them is about — but on the runner the load still fails. A
dylint/soldr/compiletest interaction, not an fbuild defect.

Rather than work around it, the step is scoped to ubuntu, and the scoping is
principled rather than a dodge: those are the lint crates' *own* tests,
asserting each lint fires on its fixture. That behavior is platform-
independent and already covered once. What the Windows leg uniquely provides
is compiling Windows-gated *workspace* source so the lints can see it — which
is the entire point of #1359, and which passes. The same reasoning scopes the
fmt loop and the three Python validators, none of which learn anything from a
second OS.

Side benefit: the Windows leg gets ~10 minutes shorter, which matters for a
job that runs on every PR push.

The Windows leg now runs exactly the steps verified locally on a Windows host:
the full sweep (0 violations) and the observed-comparison (`rows=14;
dylint_rows=14`).

Refs #1359

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* ci(dylint): pin the workflow token to contents: read

CodeRabbit: the workflow had no `permissions` block, so it inherited the
repository/organization default, which can include write access.

Every step in this job reads — checkout, a shallow `git fetch origin main` for
the shrink-only allowlist diff, and the lint runs themselves. Nothing writes,
so nothing should be able to.

Worth noting this is not yet the repo-wide convention: 8 of 106 workflows set
`permissions` today. Hardening the rest is a worthwhile sweep but belongs in
its own change rather than riding along here.

Refs #1359

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>